home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 625 < prev    next >
Encoding:
Text File  |  1996-08-06  |  4.1 KB  |  112 lines

  1. Path: chronicle.mti.sgi.com!austern
  2. From: "ian (i.) willmott" <willmott@bnr.ca>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Generic Object Callbacks
  5. Date: 04 Mar 1996 12:32:54 PST
  6. Organization: Northern Telecom
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4hfjq6$7ko@bcarh8ab.bnr.ca>
  9. References: <4h9ii0$3mlq@news-s01.ny.us.ibm.net>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=us-ascii
  13. Content-Transfer-Encoding: 7bit
  14. X-Original-Date:  Mon, 4 Mar 1996 20:28:54 +0000 
  15. Content-Identifier:  Re: Generic O... 
  16. X-Mailer: Mozilla 1.1 (X11; I; HP-UX A.09.05 9000/720) 
  17. X-Url: news:4h9ii0$3mlq@news-s01.ny.us.ibm.net 
  18. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  19.     iQBVAwUBMTtTiky4NqrwXLNJAQF4OwH/ZwwUpJZQVXh8MLBWNRf7laa62scRp+iz
  20.     rYDCSAOGT/pIyQSxWknKwSmmgZZm+X6brMJPFHPkDorU8Dd0nJQ88A==
  21.     =bdGH
  22. Originator: austern@isolde.mti.sgi.com
  23.  
  24. References: <4h9ii0$3mlq@news-s01.ny.us.ibm.net>
  25.  
  26. hickeyr@ibm.net (Rich Hickey) wrote:
  27.  
  28. >Having previously considered the suggestion you proposed and forced to solve 
  29. >the problem in current language, and with a lot of experience using a
  30. >current-language solution, I feel it is actually preferable to the extension 
  31. >you propose in the following areas:
  32. >
  33. >A)It is more type-flexible. By that I mean it is possible to produce a 
  34. >callback system that is type-safe, yet tolerant of type differences in the 
  35. >caller/callee signatures that are either implicitly convertible or can be 
  36. >ignored. For example if the caller requires a function to which it can pass 
  37. >an int and from which it expects nothing, using my library it is possible to 
  38. >bind the callback to a function that takes an int and returns an int (return 
  39. >value is ignored), or takes a long and returns void (compiler implicitly 
  40. >converts int->long). Once you get involved with polymorphism this becomes 
  41. >critical: caller passes ptr-to-derived, callee accepts ptr-to-base. Any 
  42. >language extension approach would have the rigidity normally associated with 
  43. >pointers-to-functions, i.e. exactly matching signatures required. 
  44.  
  45. I'm not sure what you mean by this. I've never heard of any requirement
  46. for "exactly matching signatures" for calls through pointers-to-function.
  47. As far as I know the matching rules are exactly the same as for ordinary
  48. function calls. The following code is accepted by Cfront v3.0
  49. without complaint:
  50.  
  51. class A {
  52.     int x;
  53. };
  54.  
  55. class B: public A {
  56.     int y;
  57. };
  58.  
  59. int (*fp)(long,A *);
  60.  
  61. long func(int i,B *p)
  62. {
  63.     return(fp(i,p));
  64. }
  65.  
  66. The proposed language extension would work the same way. It's true
  67. that this is illegal (I assume this is what you were referring to):
  68.  
  69. fp=&func;  // never mind the infinite recursion here
  70.  
  71. However, I don't see why this is a problem. You just declare your
  72. callback functions to take the most general parameters; in this
  73. example, (long,A *) instead of (int,B *). The proposed type
  74. "pointer-to-bound-member-function" is the natural analog for class
  75. member functions of the existing pointer-to-function type, and will
  76. be useful in the same contexts.
  77.  
  78. >B)It is easier to extend; to things like callbacks with stored arguments 
  79. >etc.
  80.  
  81. How so? Here's the PBMF solution:
  82.  
  83. class MyCallback {
  84.     int (class::*pbmf)(int,A *);  // language extension
  85.     int i;
  86.     A *p;
  87. public:
  88.     MyCallback((class::*pb)(int,A *),int ii,A *pp):
  89.         pbmf(pb),i(ii),p(pp) {}
  90.     int operator()
  91.         { return(pbmf(i,p)); }
  92. };
  93.  
  94. No dynamic allocation, virtual functions, casts to void *, or templates
  95. (although you could use them if you wanted to) needed. Of course, if this
  96. extension were adopted, this would not prevent other solutions from being
  97. used anywhere they were appropriate. For most cases, the built-in datatype
  98. is more convenient and type-safe.
  99.  
  100. Ian Willmott
  101. Bell-Northern Research
  102. Ottawa, Ontario
  103. (613)-763-9688
  104. willmott@bnr.ca
  105. ---
  106. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  107.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  108.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  109.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  110.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  111. ]
  112.